home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 4 / QRZ Ham Radio Callsign Database - Volume 4.iso / digests / digital / 940202.txt < prev    next >
Internet Message Format  |  1994-11-13  |  12KB

  1. Date: Mon, 20 Jun 94 04:30:23 PDT
  2. From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu>
  3. Errors-To: Ham-Digital-Errors@UCSD.Edu
  4. Reply-To: Ham-Digital@UCSD.Edu
  5. Precedence: Bulk
  6. Subject: Ham-Digital Digest V94 #202
  7. To: Ham-Digital
  8.  
  9.  
  10. Ham-Digital Digest          Mon, 20 Jun 94       Volume 94 : Issue  202
  11.  
  12. Today's Topics:
  13.                        AEA DSP2232 Mailing List
  14.                          DISTRIBUTION STATUS
  15.                  finding the freq of an xtal (3 msgs)
  16.                    GTOR evaluation/update? (2 msgs)
  17.                     Railroad track as an antenna?
  18.  
  19. Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu>
  20. Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu>
  21. Problems you can't solve otherwise to brian@ucsd.edu.
  22.  
  23. Archives of past issues of the Ham-Digital Digest are available 
  24. (by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital".
  25.  
  26. We trust that readers are intelligent enough to realize that all text
  27. herein consists of personal comments and does not represent the official
  28. policies or positions of any party.  Your mileage may vary.  So there.
  29. ----------------------------------------------------------------------
  30.  
  31. Date: 20 Jun 1994 00:01:03 +0200
  32. From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!pipex!sunic!trane.uninett.no!eunet.no!nuug!EU.net!Germany.EU.net!Aachen.Germany.EU.net!rmi.de!Aachen.Germany.EU.net!rmi.de!not-for-mail@network
  33. Subject: AEA DSP2232 Mailing List
  34. To: ham-digital@ucsd.edu
  35.  
  36. ====================================================================
  37.       This is the Mailserver at EUnet EUregio POP Aachen
  38. ====================================================================
  39.  
  40. If you are interested in exchanging information on the
  41.  
  42. AEA DSP 2232 - Digital Signal Processing Multi-Mode Data Controller
  43.  
  44. you are invited to join our Mailing list (started on May 12, 1994).
  45. Please subscribe by sending a Mail to
  46.  
  47. dsp2232-request@rmi.de   [or dsp2232-request@Aachen.Germany.EU.net]
  48. with the subject: "subscribe" .
  49.  
  50. If you would like to share your experiences of knowledge on the
  51. unit, write you contributions to
  52.  
  53. dsp2232@rmi.de   [or dsp2232@Aachen.Germany.EU.net].
  54.  
  55.  
  56. ====================================================================
  57.         Automatic weekly mailing
  58. ====================================================================
  59.  
  60. ------------------------------
  61.  
  62. Date: 19 Jun 94 16:54:16 GMT
  63. From: news-mail-gateway@ucsd.edu
  64. Subject: DISTRIBUTION STATUS
  65. To: ham-digital@ucsd.edu
  66.  
  67. SMTPGATE.HAMDIGI2     DISTRIBUTION STATUS INFORMATION      06/19/94 16:
  68. 53:00
  69. =======================================================================
  70.  
  71. DISTRIBUTION ID: SMTPGATE.HAMDIGI2.3416
  72. SUBJECT        : Ham-Digital Digest V94 #200
  73. DOCUMENT NAME  : %%DOCNAME
  74. DATE  SENT     : 06/18/94        TIME SENT: 07:56:00
  75. =======================================================================
  76.  
  77. YOUR MAIL WAS NOT DELIVERED FOR THE FOLLOWING REASON:
  78.  
  79. SNADS STATUS  : 000F
  80. X.400 CODE    : %%DIAGCODE
  81. INFORMATION   : %%SUPPLINFO
  82. EXPLANATION   : SNADS SYSTEM ERROR
  83.  
  84. =======================================================================
  85.  
  86. RECIPIENT      : CCMAIL.0060880
  87. LAST NAME      :
  88. FIRST NAME     :
  89. MIDDLE INITIAL :
  90. INITIALS       :
  91. NATIVE NAME    :
  92. COUNTRY        :
  93. ADMD           :
  94. PRMD           :
  95. ORGANIZATION   :
  96. ORG UNIT 1     :
  97. ORG UNIT 2     :
  98. ORG UNIT 3     :
  99. ORG UNIT 4     :
  100. DDA            :
  101. TITLE          :
  102. DESCRIPTION    :
  103. USERDATA       :
  104. TELEPHONE      :
  105.  
  106. ------------------------------
  107.  
  108. Date: 19 Jun 1994 13:12:22 -0400
  109. From: news1.digex.net!access.digex.net!not-for-mail@uunet.uu.net
  110. Subject: finding the freq of an xtal
  111. To: ham-digital@ucsd.edu
  112.  
  113. In article <2u0mk4$sgt@crl3.crl.com>, Acsys Inc. wrote:
  114. > I have a xtal of unknown value (~8.7mhz) that I need to find the exact
  115. > frequency of.  What is the best way to do this?  I do have a frequency
  116. > counter, sho should I build a xtal osc and use the coutner?  How bout
  117. > a simple osc made out of cmos parts like the 4011?  If so what would
  118. > be a good schematic to use to do this?  I need to be quite accurate.
  119. > thanx,
  120. > mycal
  121. The freq counter should be accurate enough, you have to find a buffered
  122. point to pick off the signal, otherwise you'll pad the crystal oscillator
  123. and throw it off frequency a bit if you go directly to it.
  124.  
  125. Andy N3LCW
  126.  
  127. ------------------------------
  128.  
  129. Date: 19 Jun 1994 12:51:01 -0400
  130. From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!news.ans.net!newstf01.cr1.aol.com!search01.news.aol.com!not-for-mail@network.ucsd.edu
  131. Subject: finding the freq of an xtal
  132. To: ham-digital@ucsd.edu
  133.  
  134. In article <2u0mk4$sgt@crl3.crl.com>, acsys@crl.com (Acsys Inc.)
  135. writes:
  136.  
  137.  
  138. I have a xtal of unknown value (~8.7mhz) that I need to find the
  139. exact
  140. frequency of.  What is the best way to do this?  I do have a
  141. frequency
  142. counter, sho should I build a xtal osc and use the coutner?  How bout
  143. a simple osc made out of cmos parts like the 4011?  If so what would
  144. be a good schematic to use to do this?  I need to be quite accurate.
  145.  
  146. thanx,
  147.  
  148. mycal
  149.  
  150. Obviously an oscillator would be a fantastic way to check your
  151. crystal.  In factr, given the circumstances, if you dont have really
  152. good test equipment, it is probably the best way.  Another way you 
  153. could test the crystal would be a with a sweep generator that is
  154. capable of going up to well beyond the frequency of the crystal, and
  155. by using a spectrum analoyzer and a generator, you should be able to
  156. sweep through the frequencies, look for the peak output and then
  157. determine the center frequency.
  158.  
  159. Build the oscillator though... simplier... :)
  160.  
  161. Prof RickD, N0NJY
  162.  
  163. ------------------------------
  164.  
  165. Date: 20 Jun 94 07:44:45 GMT
  166. From: ihnp4.ucsd.edu!sdd.hp.com!nigel.msen.com!yale.edu!noc.near.net!news.delphi.com!BIX.com!jdow@network.ucsd.edu
  167. Subject: finding the freq of an xtal
  168. To: ham-digital@ucsd.edu
  169.  
  170. domonkos@access.digex.net (Andy Domonkos) writes:
  171.  
  172. >In article <2u0mk4$sgt@crl3.crl.com>, Acsys Inc. wrote:
  173. >> 
  174. >> I have a xtal of unknown value (~8.7mhz) that I need to find the exact
  175. >> frequency of.  What is the best way to do this?  I do have a frequency
  176. >> counter, sho should I build a xtal osc and use the coutner?  How bout
  177. >> a simple osc made out of cmos parts like the 4011?  If so what would
  178. >> be a good schematic to use to do this?  I need to be quite accurate.
  179. >> 
  180. >> thanx,
  181. >> 
  182. >> mycal
  183. >> 
  184. >The freq counter should be accurate enough, you have to find a buffered
  185. >point to pick off the signal, otherwise you'll pad the crystal oscillator
  186. >and throw it off frequency a bit if you go directly to it.
  187.  
  188. >Andy N3LCW
  189.  
  190.  
  191.  
  192. Well, sorta. You have to know whether the crystal is cut for a parallel
  193. resonant mode (if so what parallel capacitance) or a series mode. Then you
  194. build a leetle oscillator that is appropriate to the crystal's mode and
  195. measure it. That tells you a little bit about the crystal. Howsosomeever,
  196. crystals are sensitive to the amount of drive you place on them, temperature
  197. (of course), pressure, etc etc. Um, just how acurate must it be? If a couple
  198. hundred parts per million are enough then a rude-crude CMOS or TTL oscillator
  199. should do. If you need it characterized to the nitties and gritties you have
  200. a whole nuther ball of fish to fry. (Hm, could I mix that metaphore worse?)
  201.  
  202. An ideal way is a VERY stable network analyzer. Place the crystal in a well
  203. calibrated fixture in shunt with the line. Slowly sweep til you see a small
  204. dip. Note the frequency and the amplitude. Then place it in series. Note the
  205. peak and dip as you tune. Then build an equivalent circuit from the results.
  206. Repeat it with higher drive levels until you see the crystal frequency change
  207. noticeably. Do not drive it within 10dB of that level if you want REAL
  208. stability. Of course, if you need this level of accuracy you're playing serious
  209. engineer and know how to do the math. Yer on yer own here. It is too long since
  210. I limped through some of this for characterising some VXO crystals. (It DOES
  211. work. The resultant VXOs very closely matched predictions, right down to when
  212. the spurious resonances would kick in and become a PITA. Your measurement WILL
  213. see them if you do it VERY patiently.)
  214. {^_^}
  215.  
  216. ------------------------------
  217.  
  218. Date: Sun, 19 Jun 94 08:36:53 MST
  219. From: ihnp4.ucsd.edu!swrinde!cs.utexas.edu!asuvax!ennews!stat!david@network.ucsd.edu
  220. Subject: GTOR evaluation/update?
  221. To: ham-digital@ucsd.edu
  222.  
  223. rogjd@netcom.com (Roger Buffington) writes:
  224.  
  225. > But would sure like to hear from actual GTOR users who have had the 
  226. > chance to really determine how it compares to Amtor and Pactor.
  227.  
  228. I have one of the new KAMPlus with both.  I really haven't seen much of
  229. a difference between GTOR and Pactor, but I've only tried it on two
  230. contacts so far, and only in conversation mode.  I haven't had the time
  231. to transfer some medium size binary files to see it works any better.
  232.  
  233. david
  234.  
  235. ---
  236. Editor, HICNet Medical Newsletter
  237. Internet: david@stat.com                 FAX: +1 (602) 451-1165
  238. Bitnet  : ATW1H@ASUACAD
  239.  
  240. ------------------------------
  241.  
  242. Date: Sun, 19 Jun 1994 21:56:01 GMT
  243. From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!usenet.ins.cwru.edu!news.csuohio.edu!sww@network.ucsd.edu
  244. Subject: GTOR evaluation/update?
  245. To: ham-digital@ucsd.edu
  246.  
  247.  
  248.  
  249. Having tested both Pactor and GTOR over a number of environments, it is plain
  250. that although GTOR offers superior performance, Pactor is more reliable.
  251.  
  252. We do quite a bit of camping.  When camping, we connect back home through a
  253. number of BBS ports that support Pactor and GTOR.  In two systems, two KAMs
  254. were placed in parallel with one on GTOR and one on Pactor.  A number of
  255. weeks have been spent then getting back to the systems from remote locations.
  256.  
  257. On an eighty meters 200 mile path, GTOR was fantastic when the band was in
  258. good to excellent condition.  We typically had to stay at the terminal to
  259. read the data that was flowing through.  The rate of data flow was high
  260. enough to be at the limit of reading it as it came in.  However, over that
  261. same path, Pactor was found to be more reliable.  When the band was opening
  262. or closing, GTOR would just not link or would do so only on stations that
  263. were not scanning.  Pactor would link fairly quickly and the link would hold.
  264. Data flow once linked would show Pactor throughput to be higher than GTOR.
  265. As much of our operation is on 80 meters as the band opens and closes, Pactor
  266. is the mode of choice for those limited to one TNC.
  267.  
  268. 73,
  269. Steve
  270.         NO8M@NO8M.#NEOH.OH.USA.NA   <<< this works best
  271.         ag807@cleveland.freenet.edu <<< this works better
  272.         the above address           <<< will not work at all
  273.  
  274. ------------------------------
  275.  
  276. Date: 19 Jun 1994 21:33:14 -0400
  277. From: ihnp4.ucsd.edu!sdd.hp.com!col.hp.com!csn!jabba.cybernetics.net!not-for-mail@network.ucsd.edu
  278. Subject: Railroad track as an antenna?
  279. To: ham-digital@ucsd.edu
  280.  
  281. STORM JAMES (s9898198@sandcastle.cosc.brocku.ca) wrote:
  282. : I have heard a legend that a college radio station (either at MIT, Tufts,
  283. : or Swarthmore) welded antenna to railroad tracks, and peeved the FCC by
  284. : broadcasting nationwide.  Is this true?  If anyone knows, please email me
  285. : (or post here)  If you do know, could you please direct me to some
  286. : documentation regarding this legend if you can.
  287. :
  288.  
  289. I don't think that this would be useful for the frequencies used for
  290. comericial radio, but the Pensylvania RR did use inductive train phones
  291. that used low frequency signal passed through the rail.  The antennas
  292. looked like hand rails on top of the cars and locos.  This worked very
  293. well for the trains, but the equipment was not at all portable, and 
  294. propigation away from the tracks was very poor.
  295.  
  296.   
  297. -- 
  298. Tim Rumph                   Concord, NC
  299. tarumph@cybernetics.net (PSE sent mail here, not to uncc.edu-ALL DONE!)
  300. kd4ows@wb4kdf.#gas.nc.usa.na   (non-hams: don't try to use this on the 
  301.                                 Internet)
  302.  
  303. ------------------------------
  304.  
  305. End of Ham-Digital Digest V94 #202
  306. ******************************
  307.